home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000089_yackd@montana.et.byu.edu_Mon Nov 1 14:30 MST 1993.msg < prev    next >
Internet Message Format  |  1994-10-30  |  2KB
  1. Received: from montana.et.byu.edu by alaska.et.byu.edu; Mon, 1 Nov 93 14:30:19 -0700
  2. Return-Path: <yackd@montana.et.byu.edu>
  3. Received: by montana.et.byu.edu; Mon, 1 Nov 93 14:30:08 -0700
  4. Date: Mon, 1 Nov 93 14:30:08 -0700
  5. From: yackd@montana.et.byu.edu (Don Yacktman)
  6. Message-Id: <9311012130.AA23849@montana.et.byu.edu>
  7. To: kane@sonata.cc.purdue.edu, yackd@alaska.et.byu.edu
  8. Subject: Re:  version numbering (Re: release of MiscKit 1.0 miscellanea)
  9. Status: RO
  10.  
  11. > The major.minor.maintenance form is quite common.  My opinion?
  12. > Use this form, with bug fixes getting maintenance increment,
  13. > minor version getting incremented on new object additions with
  14. > maintenance reset to 1. [...] the major number should
  15. > stay at 1 until such a time as it should be incremented to 2; I
  16. > think you (or the group) will know when it is time for that.
  17.  
  18. I like this the best.  (The other suggestions are interesting,
  19. but for some inexplicable reason, this one appeals to me most.
  20. Who could ever say why?)
  21.  
  22. Well, hopefully I'll get something useful done on this during the
  23. week.  With everything else, though, it's tough.  :-)
  24.  
  25. As to release frequency, I was thinking that 2 weeks would be the
  26. shortest time ever between releases, but longer is fine by me, too.
  27. Depends mostly on how much is submitted, and the seriousness of
  28. the bugs that are fixed.  (Not that a quicker release would be
  29. out of the question for _really_ major problems, but I'd prefer
  30. to average a month or so between releases, and maybe a hair
  31. longer for releases to the archive sites, depending on the content
  32. of the releases.)  This may all sound sort of wishy-washy, but I'd
  33. prefer to play it by ear at first, and see what sort of pattern
  34. develops.  And I'd definitely rather not have too many releases
  35. since people don't want to be doing re-installs every other week,
  36. in most normal circumstances!  :-)
  37.  
  38. Oh, I think I'll also leave a HISTORY file in the open on ftp.byu.edu
  39. with older versions so that people can grab different revisions to
  40. suit their needs.  I'll probably include the history file in the
  41. release itself, as well.  Seems like a good idea.
  42.  
  43. Later,
  44. -don